With the advent of increased processing power, improved video support, and multitasking operating systems in modern computer systems, it has become commonplace for computer applications to execute multiple tasks in graphical user interface (GUI) environments. Such a GUI, as distinct from a command-line interface, typically employs one or more graphical windows such as windows 2-4 depicted in FIG. 1 which provide the workspace for the end user. End users desirably interact with such workspaces by means of pointing devices, keyboards, and the like. More particularly, the user may interface with the computer system by interacting with various graphical images such as icons, cursors, etc. through keyboard entry and pointing device movements, etc. well known in the art.
One graphical system that has enjoyed immense popularity is known as the X Window System which is employed in conjunction with X Window applications executing on such a system. In such an X Window System environment, it is conventional to control such X Window applications through pointing devices and the like by iconifying and deiconifying the application, circulating it up and down, moving it to different workspaces, closing it, or the like.
One operating system commonly used in conjunction with the aforementioned X Window System environment which has also gained immense popularity in part due to its multiuser multitasking functionality is the Unix Operating System currently distributed by the Novell Corporation. In like manner to the X Window System environment, application processes may be controlled within the Unix Operating System environment. In doing so, it is possible to control such application processes in Unix by stopping, continuing, reprioritizing, or terminating the particular application process.
A difficulty arises however in systems wherein the X Window System environment is commingled with that of the Unix Operating System environment, arising in part from the differences with which applications and application processes are controlled in the respective environments. With respect to the aforementioned X applications, a characteristics thereof is that each such application may have associated therewith a window-id or a process-id. Because the X Window System environment permits execution of applications in the context of various windows, thereby affording a graphical user interface, it is typical for each such X application to have associated therewith a window-id. This is in part due to the fact that multiple windows are possible in the environment as well as execution of corresponding multiple applications, and thus it is necessary to be able to associate a given X application with windows, which is effected by means of the aforementioned window-id. In like manner, because the aforementioned X Window System environment is typically operated in conjunction with the Unix Operating System (which in turn has associated therewith the notion of multiple processes executed by the operating system), it is further conventional for a given X application to have associated therewith process-ids. These process-ids serve the similar function to window ids providing a correlation between X applications and windows in the sense that the process-ids provide the correspondence between a given X application and the processes associated therewith which may be executed by the Unix Operating System. Accordingly, X applications have associated therewith these process-ids. One serious difficulty however arises which has been troubling the industry with the combination of such X Window System environments and the Unix Operating System environment. More specifically, the difficulty arises when an application which has either such a window-id or process-id of a given X application but is in need of obtaining information and controlling the X application via the other environment. For example, an application may have available to it the process-id of an X application and it be desirable to move the application to a different workspace, having associated therewith a different window.
However, without the window-id "handle" of the X application, in accordance with the normal operating characteristics of such known X Window System environments, it is not possible to effect such a movement when the application only has access to the process-id but not the associated window-id.
A similar difficulty has arisen in the art when such an application may have available to it a window-id of an X application and further wherein it is desirable to reprioritize the X application relative to other applications or tasks executing concurrently on the system to be hereinafter described in greater detail. However, again because of the characteristics of the X Window System environment and the Unix Operating System environment, in order to effect such prioritization, in addition to the window-id being known to the application, it is further necessary for the application to have available the correlative process-id. Thus, in summary, a solution was needed to effect the ability of an application to obtain information and control an X application via the other environment, e.g., across the X Window System environment-Unix Operating System environment boundary.
The reprioritization of applications will now be described in further detail in order to further illustrate the need for the solution to the problem provided by the subject invention and but one application thereof, specifically to the problem of providing for such reprioritization of applications.
In the course of development of such GUI environments previously described and as a result of the improvements noted above, it soon became apparent that it would be desirable for several GUI applications represented by the windows of FIG. 1 to be capable of running simultaneously in a user's GUI desktop. A representative example of such an application and desktop, respectively, would be the "Motif" GUI application running in a GUI desktop known as "CDE", or the common desktop environment. Motif is a software package developed through the Open Systems Foundation (OSF), and the Common Desktop Environment (CDE) is a desktop environment distributed by the IBM Corporation, among others.
As is typical in such environments, the user is most interested at a given time only in a single active task or application (although other such tasks or applications might nevertheless also be executing concurrently). In accordance with conventional parlance, this notion of one of many tasks being active and of most interest is referred to as the task or associated window being in "focus". Naturally, because the user is most interested in this particular task, he or she desires that the computer systems provide the best response for this task as opposed to other tasks which may be also executing concurrently in a multitasking operating system.
Unfortunately, however, it is the nature of such multitasking systems that all windowed tasks executing therein (a representative example of which is the Unix operating system distributed by the Novell Corporation) operate with equal priority or access to the cpu(s) in the computer system.
Put differently, in accordance with prior art technique, all applications or tasks essentially were executed at the same CPU priority. One serious drawback with this was that if a highly CPU-intensive application was then iconified, e.g., defocused and pushed down in the stack, it nevertheless continued to consume its substantial share of the CPU processing ability, thereby essentially stealing processing time from a different currently focused window for which the user was desiring the most response.
As multitasking operating systems developed, the art progressed even further to the point that multiple workspaces, e.g., virtual screens, depicted in FIG. 2 are now provided, each such desktop space 6-9 or virtual screen being capable of executing an associated different entire suite of running GUI applications. In like manner to the previously described situation with respect to an individual task or application associated with a window, it became commonplace for present computer systems to cause each of such multiple workspaces (in addition to the individual windowed applications or tasks of FIG. 1) to execute with equal priority notwithstanding that a user was most interested in and desired the best response from a particular one of the workspaces and the application(s) or task(s) associated therewith. However, as in the case of individual applications or tasks being relegated to having the same priority regardless of which was "focused" at the time, this same drawback obtained in the case such multiple workspaces. In other words, notwithstanding that a particular such workspace such as workspace of FIG. 2 was of primary interest at a given time to a user and thereby focused, the art nevertheless gave equal priority to the remaining workspaces 7-9, thereby consuming CPU resource that could better be directed to the workspace of current interest, e.g., workspace 6.
For all the foregoing reasons, a solution was also highly desired and sought after which could remedy the foregoing situation and address the problem of non-focused applications, tasks, and workspaces consuming CPU resource at the expense of a particular application, task, or workspace which the user was interacting with and thereby in need of better performance for.